Ask Dev：贵司 DBA 是否对数据库 schema 格式严格要求？

💡 本文节选翻译自 Reddit 上讨论帖 Do DBAs impose strict requirements for database schema conventions at your org?(https://www.reddit.com/r/ExperiencedDevs/comments/xcswje/do_dbas_impose_strict_requirements_for_database/ )

背景

123android 是名开发者，他的团队正在开发一些新的微服务，需要存储一些数据。这些表完全由微服务拥有，并且它们的数据仅通过 API 公开。他司 DBA 对于数据库 schema 格式限制颇多，123android 认为添加约束会在将来导致混淆，属于给自己找事。

例①

tshirt 表被要求重命名为tshirts（因为该表包含多个 T 恤条目），这下得把域对象命名为 tshirts 以匹配表名，每个域对象表示单个 T 恤，或者手动将 T 恤映射到 tshirts 表。

例②

在数据库中有一个字段：size，由字符串表示。size 只能是 'small', 'medium' 或 'large'。在应用程序的代码中，这通过枚举强制执行，因此除了这几个值以外，没有其他值可以进入此字段。DBA 要求我们还要在表上添加约束条件来强制执行这些值。

这么多约束到底有没有必要？

DingBat99999 (29 ⬆)

在我看来，贵司 DBA 的要求没有任何一项不合理。

在我的经验中，通常在决定此类约束前会有一些讨论，比如它们到底是在应用程序中执行还是在数据库中执行。那里有没有历史故事？

不过，你当然也可以跟 DBA 说 tshirt 的尺寸取决于实现方式，也是动态的。这样他们就没有理由要求约束了。否则，你不需要它。

💬 高赞评论

在数据库中强制执行枚举约束是最佳实践，听起来你很幸运能够与一位有能力的 DBA 合作。在持久层进行严格的检查是防止垃圾数据进入系统最靠谱的方法。

ccb621 (14 ⬆)

你可以把写长文的精力用在询问 DBA 这些约束为什么重要上。如果他们还没编写指南，你可以当志愿者，帮助团队未来可以避免繁琐。

表面上看来这些要求似乎是挑刺，但是可能存在许多深层次的经验教训需要进行审查。

nutrecht (6 ⬆)

我认为出现需要遵守的数据库 schema 标准是很正常的，我以前见过。我也见过开发人员随心所欲时会出现的混乱，所以不能责怪 DBA。

因此，你举的两个例子听起来都挺合理。在数据库中使用枚举约束的好处是你永远不可能以任何方式得到「损坏」的数据，从而破坏软件。我曾经处理过测试数据库，在那里测试人员直接插入数据，处理这个非常麻烦。

因此，双方都有充分论据支持自己观点。就个人而言，我不会花费任何精力去反驳约束，特别是因为你将来可能需要 DBA 团队。

另外，作为 Java / Spring 开发人员；你应该先考虑 schema 设计。如果由于 Spring 而需要调整 schema，这多半是你的问题。

ViperRT10Matt (6 ⬆)

我们的 DBA 不会做这种事。他们只发布 & 管理开发人员提供给他们的内容。在需要更改 schema 或 schema 设计方面，他们的工作内容就像汽车的稳定控制器；只有在极端情况下才会介入，避免真正危险的情况。

AdrianC9 (4 ⬆)

我在一家中大型科技公司工作，我们确实有「DBA」，不过我不认为他们是传统的 DBA，他们负责审核数据库更改，但大多数标准都发布在公司 wiki 上，在提交数据库更改之前应该进行审查。因此，通常你知道可以期望什么。例如，我们要求表格以单数形式命名，比如 'tshirt'，正是出于你所述的原因。然后，ORM 可以轻松地正确映射所有内容。

关于 db 约束条件，很多 DBA 通常会更喜欢这种方式，因为它将更多控制权放在他们的范围内。就个人而言，我同意将可能属于业务逻辑的事物抛到数据库中并不理想，并且可能导致未来出现问题。话虽如此，问题也并不是很大：如果出现问题导致破坏时，你可以把锅扔给这条规则。

nderflow (2 ⬆)

列约束非常重要。我曾经见过一家公司因为禁用了已有的列约束而失去了成千上万的客户和数百万美元。

现代关系型数据库之所以美妙，就在于它可以强制执行完整性规则。

check-himu (2 ⬆)

我们也遵循复数约束，我对此没有非常强烈的想法。然而，从经验来说，在数据库中强制执行约束非常有帮助。随着代码的变化，总会有一个漏洞会让你不想要的数据进来。在数据库中进行最后检查可以避免这种情况，省得以后需要修复数据。

db-master (2 ⬆) aka 天舟小号

强制某种程度的一致性是常见做法。如果开发团队能够以相同的格式命名 ID, 名和姓，这可以节省许多时间。

比如 GitHub SQL Review Action https://github.com/marketplace/actions/sql-review 这类工具可以在 CI/CD 过程中强制 schema 一致性。

BB 仔的建议

Bytebase 内置了 SQL 审核能力，可帮助开发团队完成高质量的数据库变更。其能力也已集成到 GitHub 中，你可以在代码仓库中自助完成 SQL 审核工作（参考：Bytebase 提供的三种集成 SQL 审核到 GitHub 的模式），从而避免在多个工具中切换，将 SQL 审核工作前置，提高变更质量。

话说回来，当涉及到数据库 schema 变更时，建议就是不要问，如果 DBA 这么说，照着做就是了！

另 - 本文仅仅为节选，评论区不乏精彩讨论，最佳实践和思想碰撞⚡️，强烈建议大家阅读原帖。